An attacker who knows (or guesses) that a resolver uses RPZ with wildcard CNAME policies can craft query names long enough to trigger a NAMETOOLONG error condition during RPZ processing. This is not handled correctly and may lead to defeating the RPZ rule. It also may lead to an unexpected exit of the BIND 9 software.

Also the entire nonsense about making the found issues public - this is absurd and just exacerbates the asymmetry problem.

By keeping the reports private, the OSS teams can deal with the issues more on their timeline.

By making them public, they add timeline pressure and enable attackers.

Why are you making it harder on yourself?  It is the opposite of what you want to do.

If it's giving CVE credit to people who've taken the time and tokens to report these issues that concerns you, than just bundle the issues in one CVE.

ROI AI

From: ROI AI <sales () roiai ca> To: "oss-security"<oss-security () lists openwall com> Date: Wed, 20 May 2026 22:26:21 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age

People are shooting the messengers here.   The fact is - we are going through a generational security event due to the advancement of LLMs.

It is also both trivial and extremely effective to use Agentic analysis to filter security reports.

As for 'duplicates', people are claiming this when I have seen little evidence.  I reported a dozen or so to one major project and no one has yet claimed invalid or duplicate.

Moreover, if 'duplicates' are found, then that is a good signal for prioritization.

Let's stop talking about how the vulns are found and start fixing them with urgency.

ROI AI

From: Alan Coopersmith < mailto:alan.coopersmith () oracle com > To: < mailto:oss-security () lists openwall com > Date: Wed, 20 May 2026 10:52:37 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age

On 4/28/26 07:58, Jeremy Stanley wrote: I'm sorely tempted, both due to the increased volume and the risk of premature disclosure, to just assume that any vulnerability reported as a result of research using an LLM is trivially discoverable by others, and give up trying to pretend there's any point to working it under embargo. Other maintainers under similar floods seem to agree: Linux kernel: - https://lkml.org/lkml/2026/5/17/896 - https://docs.kernel.org/process/security-bugs.html DNS servers (BIND, Unbound, PowerDNS): - https://indico.dns-oarc.net/event/56/contributions/1233/ - https://indico.dns-oarc.net/event/56/contributions/1233/attachments/1180/2539/presentation.pdf -- -Alan Coopersmith- mailto:alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited.

On 20 May 2026, Internet Systems Consortium disclosed six vulnerabilities affecting our BIND 9 software:

- CVE-2026-3039: BIND 9 server memory exhaustion during GSS-API TKEY negotiation https://kb.isc.org/docs/cve-2026-3039 - CVE-2026-3592: Amplification vulnerabilities via self-pointed glue records https://kb.isc.org/docs/cve-2026-3592 - CVE-2026-3593: Heap use-after-free vulnerability in BIND 9 DNS-over-HTTPS implementation https://kb.isc.org/docs/cve-2026-3593 - CVE-2026-5946: Invalid handling of CLASS != IN https://kb.isc.org/docs/cve-2026-5946 - CVE-2026-5947: SIG(0) validation during query flood may lead to undefined behavior https://kb.isc.org/docs/cve-2026-5947 - CVE-2026-5950: Unbounded resend loop in BIND 9 resolver https://kb.isc.org/docs/cve-2026-5950

New versions of BIND 9 are available:

- https://downloads.isc.org/isc/bind9/9.18.49/ - https://downloads.isc.org/isc/bind9/9.20.23/ - https://downloads.isc.org/isc/bind9/9.21.22/

For more information and other release formats, consult the ISC software download page: https://www.isc.org/download/

With the public announcement of these vulnerabilities, the embargo period is ended and any updated software packages that have been prepared may be released.

-- Best regards, Michał Kępień

As dhclient is building an environment to pass to dhclient-script, it may need to resize the array of string pointers. The code which expands the array incorrectly calculates its new size when requesting memory, resulting in a heap buffer overrun.

A specially crafted packet can cause dhclient to overrun its buffer of environment entries. This can result in a crash, but it may be possible to leverage this bug to achieve remote code execution.

An attacker can send a notify request that causes a new secondary domain to be added to the bind backend, but causes said backend to update its configuration to an invalid one, leading to the backend no longer able to run on the next restart, requiring manual operation to fix it.

On 25 March 2026, Internet Systems Consortium disclosed four vulnerabilities affecting our BIND 9 software:

- CVE-2026-1519: Excessive NSEC3 iterations cause high CPU load during insecure delegation validation https://kb.isc.org/docs/cve-2026-1519 - CVE-2026-3104: Memory leak in code preparing DNSSEC proofs of non-existence https://kb.isc.org/docs/cve-2026-3104 - CVE-2026-3119: Authenticated query containing a TKEY record may cause named to terminate unexpectedly https://kb.isc.org/docs/cve-2026-3119 - CVE-2026-3591: A stack use-after-return flaw in SIG(0) handling code may enable ACL bypass https://kb.isc.org/docs/cve-2026-3591

New versions of BIND 9 are available:

- https://downloads.isc.org/isc/bind9/9.18.47/ - https://downloads.isc.org/isc/bind9/9.20.21/ - https://downloads.isc.org/isc/bind9/9.21.20/

For more information and other release formats, consult the ISC software download page: https://www.isc.org/download/

With the public announcement of these vulnerabilities, the embargo period is ended and any updated software packages that have been prepared may be released.

-- Nicki Křížek (they/them)

New versions of Kea are available:

- https://downloads.isc.org/isc/kea/2.6.5/ - https://downloads.isc.org/isc/kea/3.0.3/

-- Peter Davies Support Engineer Internet Systems Corporation peterd () isc org 001 650-423-1460

On 21 January 2026, Internet Systems Consortium disclosed one vulnerability affecting our BIND 9 software:

- CVE-2025-13878: Malformed BRID/HHIT records can cause named to terminate unexpectedly https://kb.isc.org/docs/cve-2025-13878

New versions of BIND 9 are available:

- https://downloads.isc.org/isc/bind9/9.18.44/ - https://downloads.isc.org/isc/bind9/9.20.18/ - https://downloads.isc.org/isc/bind9/9.21.17/

Operators and package maintainers who prefer to apply patches selectively can find individual vulnerability-specific patches in the "patches" subdirectory of each above directory.

For more information and other release formats, consult the ISC software download page: https://www.isc.org/download/

With the public announcement of these vulnerabilities, the embargo period is ended and any updated software packages that have been prepared may be released.

-- Best regards, Michał Kępień

On 22 October 2025 we (Internet Systems Consortium) disclosed three vulnerabilities affecting our BIND 9 software:

- CVE-2025-8677: Resource exhaustion via malformed DNSKEY handling https://kb.isc.org/docs/cve-2025-8677 - CVE-2025-40778: Cache poisoning attacks with unsolicited RRs https://kb.isc.org/docs/cve-2025-40778 - CVE-2025-40780: Cache poisoning due to weak PRNG https://kb.isc.org/docs/cve-2025-40780

New versions of BIND 9 are available from https://www.isc.org/downloads

Operators and package maintainers who prefer to apply patches selectively can find individual vulnerability-specific patches in the "patches" subdirectory of each published release directory:

- https://downloads.isc.org/isc/bind9/9.18.41/patches/ - https://downloads.isc.org/isc/bind9/9.20.15/patches/ - https://downloads.isc.org/isc/bind9/9.21.14/patches/

With the public announcement of these vulnerabilities, the embargo period is ended and any updated software packages that have been prepared may be released.

-- Best regards, Michał Kępień

On 10 September 2025 we (Internet Systems Consortium) disclosed one vulnerability affecting our Stork software:

- CVE-2025-8696: DoS attack against the Stork UI from an unauthorized user https://kb.isc.org/docs/cve-2025-8696

New version(s) of Stork are available at the following URL(s):

Stable: https://downloads.isc.org/isc/stork/2.2.1/

With the public announcement of these vulnerabilities, the embargo period is ended and any updated software packages that have been prepared may be released.

Please note that CVE-2025-8696 also affects the current Stork development version, 2.3.0. Anyone who has Stork 2.3.0 deployed is advised to employ mitigations until 2.3.1 is released, currently planned for October 6, 2025.

-- Ben Scott Support Engineer Internet Systems Consortium

New versions of Kea are available at the following URLs:

Stable: https://downloads.isc.org/isc/kea/3.0.1/

Development: https://downloads.isc.org/isc/kea/3.1.1/ -- Ben Scott <bscott () isc org> Support Engineer Internet Systems Consortium

UNSUBSCRIBE

From: Andrei Pavel <andrei () isc org> Sent: Wednesday, May 28, 2025 12:34 PM To: oss-security () lists openwall com Cc: security-officer () isc org Subject: [oss-security] ISC has disclosed three vulnerabilities in Kea (CVE-2025-32801, CVE-2025-32802, CVE-2025-32803)

On 28 May 2025 we (Internet Systems Consortium) disclosed three vulnerabilities affecting our Kea software: - CVE-2025-32801:  Loading a malicious hook library can lead to local privilege escalation https: //kb. isc.  org/docs/cve-2025-32801 ZjQcmQRYFpfptBannerStart This Message Is From an Untrusted Sender You have not previously corresponded with this sender. Report Suspicious <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/CnbCELObTUL5LY!IfMr12grbHCMGIeYwb5CRtYoOgfehO26TI0in2gmuaj2ZsS-Cc02EGYKPtCDZ809tra1TsFSW0eMGQScNcg8JV$> ‌ ZjQcmQRYFpfptBannerEnd

On 28 May 2025 we (Internet Systems Consortium) disclosed three

vulnerabilities affecting our Kea software:

- CVE-2025-32801: Loading a malicious hook library can lead to

local privilege escalation https://kb.isc.org/docs/cve-2025-32801

- CVE-2025-32802: Insecure handling of file paths allows multiple

local attacks https://kb.isc.org/docs/cve-2025-32802

- CVE-2025-32803: Insecure file permissions can result in

confidential information leakage https://kb.isc.org/docs/cve-2025-32803

New versions of Kea are available from https://www.isc.org/downloads

- https://downloads.isc.org/isc/kea/2.4.2/

- https://downloads.isc.org/isc/kea/2.6.3/

- https://downloads.isc.org/isc/kea/2.7.9/

With the public announcement of these vulnerabilities, the embargo

period is ended and any updated software packages that have been

prepared may be released.

Hello list,

we originally reported these issues to upstream and would like to share our full report below.

This is a report about local security issues in the Kea DHCP server suite. During a routine review we found a local root exploit and a number of further local vulnerabilities in its REST API, affecting Kea packages found in many Linux and BSD distributions.

Upstream pre-disclosed these issues to the distros mailing list on 2025-05-15 and published bugfix releases today. A rendered HTML version of this report is also available on our blog [1].

1) Introduction ===============

The Kea DHCP distribution [2] is the next generation DHCP server suite offered by the Internet Systems Consortium (ISC). It replaces the traditional ISC DHCP software which has reached its end of life [3].

Since SUSE is also going to ship Kea DHCP in its products, we performed a routine review of its code base. Even before checking the network security of Kea, we stumbled over a range of local security issues, among them a local root exploit which is possible in many default installations of Kea on Linux and BSD distributions. This, as well as some other issues and security recommendations for Kea follow below in a detailed report.

This report is based on Kea release 2.6.1 [4]. Any source code references in this report relate to this version. Many systems still ship older releases of Kea, but we believe they are all affected as well by the issues described in this report.

In the next section an overview of the Kea design, as far as it is relevant for the issues in this report, is provided. In section 3) the security issues we found will be discussed in detail. In section 4) further hardening suggestions are provided. In section 5) the upstream bugfixes for the issues are discussed. In section 6) the packaging properties and affectedness of Kea in widespread Linux and UNIX systems are documented. Finally in section 7) an overview of the CVE assignments is given.

2) Overview of Kea Design =========================

This section provides a short overview of the involved components, to allow readers that are unfamiliar with Kea to better understand the rest of this report.

Kea offers three separate services for dhcp4, dhcp6 and dhcp-ddns. A kea-ctrl-agent is active by default in most Kea installations and offers an HTTP REST API listening on localhost:8000. This REST API is based on JSON requests that are either processed by kea-ctrl-agent itself or forwarded to one of the Kea services it controls. To allow forwarding, each Kea service listens on a UNIX domain socket that is only accessible to kea-ctrl-agent.

In most installations, the REST API is by default accessible to all users in the system without authentication. Many installations run the Kea services with full root privileges. On Linux systems that use a dedicated service user account instead, the Linux capability CAPNETBINDSERVICE is assigned to all of the Kea services. The dhcp4 service additionally needs CAPNETRAW to function.

The default configuration and the packaging of Kea are important aspects to judge the exploitability of the issues described in this report. In some sense, the issues could be considered vendor-specific problems and not upstream issues (some ISC engineers argued in this direction when we first reported these issues). The number of affected Kea packages and the fact that the default configuration installed by the Kea build system also enables an unauthenticated REST API make these seem like overarching upstream issues to us, however.

3) Security Issues ==================

3.1) Local Privilege Escalation by Injecting a Hook Library via the set-config Command (CVE-2025-32801) ---------------------------------------------------------------------------------------------------------

The set-config REST API command allows to completely control the configuration of kea-ctrl-agent itself, as well as of the individual Kea services. A trivial local privilege escalation is possible by configuring a hook library under control of an unprivileged user. The following example uses the curl utility to perform the exploit.

someuser$ curl -X POST -H "Content-Type: application/json" \ -d '{ "command": "config-set", "arguments": { "Control-agent": {"hooks-libraries": [{"library": "/home/someuser/libexploit.so"}] }}}' \ localhost:8000

By placing a constructor function into libexploit.so, attacker controlled code will be executed by kea-ctrl-agent upon dlopen() of the library. The impact is arbitrary code execution with full root privileges on installations that run Kea services as root. On systems that use a dedicated service user for Kea, the impact will be full control over the Kea processes and also escalated networking privileges.

Hook libraries can be configured for any of the other Kea services as well, thus code execution can be achieved in the context of each of the Kea daemons this way.

Attach to this email is a simple Python script kea-hook-lib-exploit.py which can be used to reproduce the issue.

3.2) Arbitrary File Overwrite via config-write Command (CVE-2025-32802) -------------------------------------------------------------------------

The config-write REST API command instructs a Kea service to write out its configuration to an arbitrary file path:

curl -X POST -H "Content-Type: application/json" \ -d '{ "command": "config-write", "arguments": { "filename": "/etc/evil.conf" } }' \ localhost:8000

The file write happens via a regular C++ std::ofstream with trunc setting, i.e. the target file will be truncated and overwritten if it already exists. The configuration content that is written to disk can as well be controlled by the attacker, but the JSON format and configuration sanity checks that are enforced by Kea restrict the degree of freedom of what will eventually be written out.

If the Kea services run with full root privileges, then this is a local denial-of-service bordering on a local root exploit. By embedding shell code, a crafted JSON configuration written e.g. to a file in /etc/profile.d could trigger a local root exploit upon root logging in, for example.

If the Kea services are running as dedicated service users, then this attack vector can be used to corrupt Kea-owned configuration, log and state files, thus resulting in integrity violation and denial-of-service limited to the scope of the Kea services.

3.3) Redirection of Log Files to Arbitrary Paths (shared CVE with 3.2) ----------------------------------------------------------------------

This is similar to issue 3.2): an arbitrary new logfile path can be configured to be used by Kea services. This is an example JSON configuration that demonstrates the problem:

{ "command": "config-set", "arguments": { "Control-agent": { "loggers": [{ "name": "kea-ctrl-agent", "output-options": [{ "output": "/root/bad.log" }], "severity": "DEBUG" }] } } } }

This configuration causes kea-ctrl-agent to create the file /root/bad.log and also to change logging severity to DEBUG, potentially exposing sensitive internal program state. Also a lock file will be created in /root/bad.log.lock.

This attack vector poses another local denial-of-service vulnerability bordering on a local root exploit, similar to what is outlined in section 3.2).

3.4) Service Spoofing with Sockets in /tmp (shared CVE with 3.2) ------------------------------------------------------------------

For the purposes of forwarding a REST API request to one of the Kea services, kea-ctrl-agent attempts to connect to the service's UNIX domain socket. If a legit Kea admin tries to send a command to a Kea service that is not currently running, like the kea-dhcp-ddns service (which isn't configured by default on most distributions), then the admin can fall victim to a local service spoofing attack.

Whether this is possible depends upon the directory into which the UNIX domain sockets are placed. Many distributions use the public /tmp directory for this. In this case an unprivileged local user can create the UNIX domain socket in question on its own, for example in /tmp/kea-ddns-ctrl-socket. If this succeeds, then API requests will be forwarded to a spoofed service that can respond with a crafted reply. With this a local attacker can attempt to trick the admin into performing dangerous actions, or might be able to intercept sensitive data contained in the request forwarded to the spoofed service.

We reproduced this attack vector for example on Fedora 41 as follows:

curl -X POST -H "Content-Type: application/json" \ -d '{ "command": "config-get", "service": [ "d2" ], "arguments": { "secret": "data" } }' \ localhost:8000

The d2 service socket is configured by default in kea-ctrl-agent and refers to the kea-dhcp-ddns service. When running strace on kea-ctrl-agent then the following connect() attempt is observed during this request:

connect(18, {safamily=AFUNIX, sunpath="/tmp/kea-ddns-ctrl-socket"}, 27) = -1 ENOENT (No such file or directory)

A local unprivileged user can bind a UNIX domain socket in /tmp/kea-ddns-ctrl-socket to intercept any such requests.

This attack type also affects Kea services that are configured but not yet running, e.g. before the Kea service unit or init script is started, or when Kea services are restarted. Upon startup each service will attempt to unlink() the UNIX domain socket path before binding to it, but this is subject to a race condition that unprivileged users can win by rebinding a socket in this location before the legit service has a chance to do so. The legit service will then fail to start, while the unprivileged user will be able to intercept REST API requests that are forwarded to the spoofed service by kea-ctrl-agent.

3.5) Denial-of-Service issues with Sockets in /tmp (shared CVE with 3.2) --------------------------------------------------------------------------

The use of the /tmp directory for the Kea service sockets is generally problematic. The Kea services create lock files in the socket directory that are derived from the socket names. Any local user can pre-create either the UNIX domain sockets or the associated lock files to prevent Kea services from starting.

3.6) World-Readable DHCP Lease Files in /var/lib/kea/.cvs (CVE-2025-32803) ----------------------------------------------------------------------------

Many of the distributions we checked grant read access to the state data of the default Kea in-memory database, which is in most cases found in /var/lib/kea. This means all local users will be able to access this information and thereby this poses a local information leak. Whether DHCP leases are private data is debatable. More sensitive data might be stored in these files (in a future implementation), however.

We don't recommend to allow general read access to this data. We originally only reported this as a hardening recommendation, but upstream decided to assign a CVE for it anyway.

3.7) World-Readable Kea Log Files (shared CVE with 3.6) -------------------------------------------------------

On most systems we checked, the Kea log files found in /var/log/kea or /var/log/kea.log are world-readable. As a hardening measure we recommend to restrict access to this data.

We originally only reported this as a hardening recommendation, but upstream decided to assign a CVE for it anyway.

4) Hardening Suggestions ========================

This section contains further hardening suggestions about issues that we don't consider high severity at the moment.

4.1) Possible Timing Attack against the HTTP Basic Auth Implementation ----------------------------------------------------------------------

kea-ctrl-agent uses the HTTP Basic Auth mechanism to implement authentication on the REST API interface. In this scheme the string "<username>:<password>" is base64 encoded and placed into an "Authorization:" HTTP header.

The verification of these credentials happens in BasicHttpAuthConfig::checkAuth() [5]. The code maintains a std::unorderedmap<std::string, std::string>, where the keys consist of the base64 encoded "<username>:<password>" combinations found in the Kea configuration. The values are the cleartext usernames that can be authenticated with the credentials found in the key.

In basicauthconfig.cc:365 [6] the credentials provided by the REST API client are looked up directly in this map data structure to verify them. The verification of cleartext passwords can suffer from timing attack weaknesses when the passwords are compared using optimized string comparison routines. Attackers can perform statistical analysis of the time required by a service to report an authentication failure to construct, little by little, a valid user/password combination.

In the case of kea-ctrl-agent it isn't plaintext passwords that are compared, but the base64 encoded "<username>:<password>" strings. This adds a bit of complexity but does not prevent a timing attack from succeeding. A bigger hurdle is the use of the std::unorderedmap, however, which uses a hash function to lookup elements in the map. When using the gcc compiler suite and the libstdc++ standard library, then the default hash function used for std::string is MurmurHash2 [7] with a static seed [8]. While the hash lookup complicates a possible timing attack, it is still a deterministic algorithm and an attacker might be able to choose input values in a way that causes kea-ctrl-agent to produce hash values for the hash map lookup that are suitable for a timing attack.

To be on the safe side we suggest to supply a custom KeyEqual template parameter to the std::unorderedmap. This key comparison function should implement a constant-time comparison of the input data to avoid any observable timing differences.

Since the complexity of such a timing attack, given the circumstances, will be very high, we don't see this as a relevant security issue at the moment. A dedicated attacker might be willing to make an attempt at this and succeed, however.

4.2) API Credentials Leak via 'get-config' Command --------------------------------------------------

When API authorization is enabled in the REST API, then the configuration potentially contains cleartext user names and passwords that can be used for authentication. A user that already has a valid set of credentials can discover the credentials of other users by retrieving the configuration via the API, even if the configuration file would otherwise not be world-readable in the system.

This means that any user with valid credentials can impersonate any other user. This can also be problematic when the credentials of a user are revoked at some point. By storing the credentials of other users, such a user could still access the API even after being denied access to Kea. Another issue could be that users might be reusing the same credentials for other, unrelated services.

Cleartext credentials should never be exposed on the API level, except maybe if the client is root anyway. Even then it could be a source of information leaks, for example if an admin shares a Kea configuration dump (e.g. for debugging purposes), unaware of the fact that cleartext credentials are contained in the data.

Users of Kea can circumvent this problem by avoiding storing cleartext credentials in the Kea configuration and instead referring to credential files on disk that are only accessible to privileged users.

5) Bugfixes ===========

In our initial report we suggested to upstream to restrict paths from where hook libraries are loaded (issue 3.1) and also paths where configuration and log files are written to (issues 3.2, 3.3). It is obvious, however, that the unauthenticated REST API is problematic beyond the concrete exploit scenarios we explored. Arbitrary users in the system should not be able to fully control Kea's configuration, for example. Thus we advised to enforce authentication on REST API level by default.

To fix the issues described in this report, upstream published bugfix releases for all currently supported versions of Kea:

- Release 2.4.2 [9] - Release 2.6.3 [10] - Release 2.7.9 [11]

We looked into release 2.6.3 and believe the bugfixes are thorough. As is also documented in the upstream release notes [12], the following changes have been introduced:

- For many operations only safe directories are allowed for reading from or writing to. Among others this covers the following aspects: - Hook libraries can only be loaded from a trusted system directory (addresses issue 3.1). - Configuration files can only be written to the trusted system configuration directory (addresses issue 3.2). - Logfiles can only be written to the log directory determined during build time (addresses issue 3.3). - The default configuration files installed by Kea now enforce authentication of the REST API. - The log, state and socket directories are now installed without the world readable / world writable bits set (addresses issues 3.5, 3.6, 3.7). - Sockets are now placed under /var/run/kea by default. This directory must not be world-writable (addresses issue 3.5). - The documentation and example files have been updated to avoid issues like discussed in this report.

The hardenings for the issues described in section 4) are not yet available, but upstream intends to address them in the near future.

6) Affectedness of Kea Configurations on Common Linux and UNIX Systems ======================================================================

Kea is a cross-platform project that also targets traditional UNIX systems, which might be the reason why there are no well established standards for the packaging of Kea. Every distribution integrates Kea in its own way, leading to a complex variety of outcomes with regards to affectedness. The defaults and the resulting affectedness on a range of current well-known Linux and BSD systems are documented in detail in this section.

All systems we looked at have been updated to the most recent package versions on 2025-05-23.

6.1) Arch Linux ---------------

|System Release | rolling release (as of 2025-05-23) | |Kea Version | 2.6.1 | |Kea Credentials| root:root | |Kea Socket Dir | /tmp | |Kea Log Dir | /var/log/kea-.log, mode 0644 | |Kea State Dir | /var/lib/kea, mode 0755 | |Affected By | 3.1 through 3.7 |

Arch Linux is affected by all the issues.

6.2) Debian Linux -----------------

|System Release | 12.10, 12.11 (Bookworm) | |Kea Version | 2.2.0 | |Kea Credentials| kea:kea | |Kea Socket Dir | /run/kea, owned by kea:kea mode 0755 | |Kea Log Dir | /var/log/kea, owned by kea:kea mode 0750 | |Kea State Dir | /var/lib/kea, mode 0755 | |Affected By | 3.2 (partially), 3.3 (partially), 3.6 |

When we first discovered these issues we looked into Debian 12.10. Meanwhile Debian 12.11 has been released. The situation seems to be the same in both versions, however.

No local root exploit is possible here, because the services run as non-root. Debian also applies an AppArmor profile to Kea services. This makes the hook library injection (3.1) difficult. For the injection to succeed, a directory would be needed that can be written to by the attacker and from where the Kea service is allowed to read and map a library. This seems not possible in the current AppArmor profile used for Kea. Due to this, Debian is not affected by 3.1) at all.

3.2) and 3.3) only affect files owned by kea and that are allowed to be written to according to AppArmor configuration. This still allows to corrupt the log, lock and state files owned by kea.

The only information leak is found in the state directory (3.6); logs are protected.

AppArmor Security

We checked more closely if there is a loophole in the Kea AppArmor profiles to make arbitrary code execution (3.1) possible after all. The profiles for the dhcp4, dhcp6 and ddns Kea services allow reading and mapping of files found in /home//.Private/, with the restriction that the files must be owned by kea. An attacker with a home directory can place an injection library in its $HOME/.Private/libexploit.so. Only the ownership of the file is preventing the exploit from succeeding.

By leveraging issue 3.2), the Kea services can be instructed to create kea owned files in the attacker's $HOME/.Private. The content of the created files is not fully attacker controlled, however, so it will not be possible to craft a valid ELF object for loading via dlopen() this way. By placing a setgid-directory in $HOME/.Private/evil-dir, any files created in this directory will even have the group-ownership of the attacker. The file mode will be 0644, however, so the attacker is still not able to write to the file. Our research shows that there is only a very thin line of defense left against this arbitrary code execution in kea:kea context on Debian, but it seems to hold.

6.3) Ubuntu Linux -----------------

|System Release | 24.04.02 LTS | |Kea version | 2.4.1 | |Kea Credentials| kea:kea | |Kea Socket Dir | /run/kea, owned by kea:kea mode 0755 | |Kea Log Dir | /var/log/kea, owned by kea:kea mode 0750 | |Kea State Dir | /var/lib/kea, mode 0755 | |Affected By | 3.6 |

Ubuntu is mostly equivalent to the situation on Debian Linux with one major difference: REST API access authentication is enforced either by configuring a custom "user:password" pair, or by generating a random password. If no password is configured, kea-ctrl-agent will not start.

Due to this, Ubuntu is not affected by 3.1 and 3.2 at all. Only the information leak in the state directory (3.6) exists.

6.4) Fedora Linux -----------------

| | Fedora 41 | Fedora 42 | | --------------| ------------------------------------------ | ------------------------------------------ | |Kea Version | 2.6.1 | 2.6.2 | |Kea Credentials| kea:kea | " | |Kea Socket Dir | /tmp | " | |Kea Log Dir | /var/log/kea, mode 0755 | /var/log/kea mode 0750 | |Kea State Dir | /var/lib/kea, mode 0750 | " | |Affected By | (all limited to the kea:kea credentials) | (all limited to the kea:kea credentials) | | | 3.1, 3.2, 3.3, 3.4, 3.5, 3.7 | 3.1, 3.2, 3.3, 3.4, 3.5 |

When we first discovered these issues we looked into Fedora 41. Meanwhile Fedora 42 has been released. There are some changes found in Fedora 42, most notably a safer mode for /var/log/kea.

No local root exploit is possible on Fedora, because the services run as non-root.

Items 3.1 and 3.2 only affect Kea integrity and escalation of the CAPNETRAW and CAPNETBINDSERVICE capabilities. There is no SELinux policy in effect for Kea, thus there are no additional protection layers present that would prevent arbitrary code execution in the context of kea:kea (3.1).

Fedora is affected by 3.3, 3.4 and 3.5 within the constraints of the kea:kea credentials. On Fedora 41 there exists an information leak in the log directory (3.7). The state directory is safe on both Fedora versions.

6.5) Gentoo Linux -----------------

|-------------- | ----------------------------------------------------- | |System Release | rolling release (as of 2025-05-23) | |Kea Version | 2.4.1 | |Kea Credentials| root:root | |Kea Socket Dir | /run/kea owned by dhcp:dhcp mode 0750 | |Kea Log Dir | /var/log/kea, owned by root:dhcp mode 0750 | |Kea State Dir | /var/lib/kea, owned by root:dhcp mode 0750 | |Affected By | if kea-ctrl-agent is manually enabled: 3.1, 3.2, 3.3|

On Gentoo Linux Kea is only available as an unstable ~amd64 ebuild. It seems still incomplete, because the default configuration is broken (wrong paths) and the services won't start. Also the kea-ctrl-agent is not part of the default configuration.

The directory permissions are inconsistent with the root:root credentials the Kea services are running with. This creates opportunities for a compromised dhcp user/group to stage symlink attacks in /run/kea, for example.

There are no information leaks and the /tmp directory is not used for sockets. Since the agent is not configured by default at all, we consider that Gentoo is not affected by any of the issues.

When kea-ctrl-agent is actively added to the mix and authorization is not enabled on the REST API, then Gentoo would be affected by issues 3.1, 3.2 and 3.3.

6.6) openSUSE Tumbleweed ------------------------

| System Release | rolling release (as of 2025-04-01) | rolling release (as of 2025-05-23) | | ----------------- | -------------------------------------------------- | ------------------------------------------------------------ | | Kea Version | 2.6.1 | 2.6.2 | | Kea Credentials | root:root | keadhcp:keadhcp | | Kea Socket Dir | /tmp | /tmp | | Kea Log Dir | /var/log/kea, owned by keadhcp:keadhcp mode 0755 | mode changed to 0750 | | Kea State Dir | /var/lib/kea, owned by root:root mode 0755 | /var/lib/kea, owned by keadhcp:keadhcp mode 0750 | | Affected By | 3.1 through 3.7 | (all limited to keadhcp credentials) 3.1, 3.2, 3.3, 3.4, 3.5 |

When we first discovered these issues, openSUSE Tumbleweed was fully affected by all of them. We asked our Kea maintainer to harden the packaging already before the publication of these issues, which was possible without disclosing any information about the vulnerabilities. In the current packaging on openSUSE Tumbleweed Kea no longer runs as root and the systemd unit has ProtectSystem=full enabled, which adds another layer of defense. The information leaks in /var/log/kea and /var/lib/kea have been fixed as well.

The more disruptive changes have been delayed until the general publication of these issues and will soon be addressed as well.

6.7) FreeBSD ------------

|System Release | 14.2 | |Kea Version | 2.6.1 | |Kea Credentials| root:root | |Kea Socket Dir | /tmp | |Kea Log Dir | /var/log/kea-\.log, owned by root:root mode 0644| |Kea State Dir | /var/db/kea, owned by root:wheel mode 0755 | |Affected By | 3.1 through 3.7 |

FreeBSD is affected by all the issues.

6.8) NetBSD (pkgsrc binary) ---------------------------

|System Release | 10.1 | |Kea Version | 2.6.1 | |Kea Credentials| root:root | |Kea Socket Dir | /tmp | |Kea Log Dir | /var/log/kea-\.log, owned by root:wheel mode 0644 | |Kea State Dir | /var/lib/kea, owned by root:wheel mode 0755 | |Affected By | if example configuration is used unmodified: 3.1 through 3.7 |

NetBSD supports the installation of a pkgsrc [13] binary distribution of Kea, which is also available on some other systems like MacOS. This distribution of Kea is affected by all the issues.

By default no configuration is active, however. Admins have to copy over the configuration from example files found in /usr/pkg/share/examples/kea. Thus it is debatable whether NetBSD is affected in default installations of Kea.

6.9) OpenBSD ------------

|System Release | 7.6 | 7.7 | |Kea Version | 2.4.1 | " | |Kea Credentials| root:root | " | |Kea Socket Dir | /var/run/kea, owned by root:kea mode 0775 | " | |Kea Log Dir | redirected to syslog (world-readable) | " | |Kea State Dir | /var/lib/kea, owned by root:kea mode 0775 | mode 0750 | |Affected By | 3.1, 3.2, 3.3, 3.6, 3.7 | 3.1, 3.2, 3.3, 3.7 |

When we first discovered these issues we looked into OpenBSD 7.6. Meanwhile OpenBSD 7.7 has been released. As far as we can see only the mode of the /var/lib/kea directory changed in this release.

OpenBSD is affected by issues 3.1, 3.2 and 3.3. Sockets are placed in a dedicated directory, thus 3.4 and 3.5 do not apply here. There exist information leaks for log and state data (the latter only in release 7.6).

The kea group ownership for the socket and state dir is inconsistent with the actual daemon credentials. A compromised kea group could stage symlink attacks in these directories.

7) CVE Assignments ==================

Kea upstream assigned the following CVEs. Some of them are cumulative and cover multiple of the issues found in this report.

| CVE | Corresponding Issues | Description | | -------------- | -------------------- | ------------------------------------------------------------------------- | | CVE-2025-32801 | 3.1 | Loading a malicious hook library can lead to local privilege escalation. | | CVE-2025-32802 | 3.2, 3.2, 3.4, 3.5 | Insecure handling of file paths allows multiple local attacks. | | CVE-2025-32803 | 3.6, 3.7 | Insecure file permissions can result in confidential information leakage. |

Timeline ========

- 2025-04-01: We reported the findings via a private issue [14] in the ISC GitLab. - 2025-04-02: After some initial controversial discussions, Kea upstream decided to accept the offer for coordinated disclosure and to work on bugfixes. - 2025-04-10: Upstream assigned CVEs for the issues. - 2025-04-29: Upstream communicated a coordinated release date of 2025-05-28 and their intention to involve the distros mailing list [15] 5 days earlier. Given the range of affected distributions and the severity of the issues, we suggested to involve the distros mailing list already 10 days before publication. - 2025-05-15: Kea upstream pre-disclosed the vulnerabilities to the distros mailing list [15]. - 2025-05-22: Kea upstream shared links to private bugfix releases 2.4.2, 2.6.3, and 2.7.9, containing fixes for the issues, both with the distros mailing list and in the private GitLab issue. - 2025-05-26: We inspected the differences between version 2.6.2 and version 2.6.3 and found the bugfixes to be thorough. - 2025-05-28: Publication happened as planned.

References ==========

- SUSE Bugzilla review bug for Kea [16] - ISC Kea project page [2] - ISC GitLab private issue detailing the issues from this report [14]

[1]: https://security.opensuse.org/2025/05/28/kea-dhcp-security-issues.html [2]: https://www.isc.org/kea [3]: https://www.isc.org/blogs/isc-dhcp-eol [4]: https://github.com/isc-projects/kea/tree/Kea-2.6.1 [5]: https://gitlab.isc.org/isc-projects/kea/-/blob/Kea-2.6.2/src/lib/http/basicauthconfig.cc?reftype=tags#L342 [6]: https://gitlab.isc.org/isc-projects/kea/-/blob/Kea-2.6.2/src/lib/http/basicauthconfig.cc?reftype=tags#L365 [7]: https://github.com/gcc-mirror/gcc/blob/97a36b466ba1420210294f0a1dd7002054ba3b7e/libstdc%2B%2B-v3/libsupc%2B%2B/hashbytes.cc#L74 [8]: https://github.com/gcc-mirror/gcc/blob/97a36b466ba1420210294f0a1dd7002054ba3b7e/libstdc%2B%2B-v3/include/bits/functionalhash.h#L205 [9]: https://downloads.isc.org/isc/kea/2.4.2 [10]: https://downloads.isc.org/isc/kea/2.6.3 [11]: https://downloads.isc.org/isc/kea/2.7.9 [12]: https://downloads.isc.org/isc/kea/2.6.3/Kea-2.6.3-ReleaseNotes.txt [13]: https://pkgsrc.org [14]: https://gitlab.isc.org/isc-projects/kea/-/issues/3825 [15]: https://oss-security.openwall.org/wiki/mailing-lists/distros [16]: https://bugzilla.suse.com/showbug.cgi?id=1234265

-- Matthias Gerstner <matthias.gerstner () suse de> Security Engineer https://www.suse.com/security GPG Key ID: 0x14C405C971923553 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich

On Tue, Jul 23, 2024 at 01:59:07PM +0000, Aram Sargsyan wrote: On 23 July 2024 we (Internet Systems Consortium) disclosed four vulnerabilities affecting our BIND 9 software:

- CVE-2024-1975: SIG(0) can be used to exhaust CPU resources https://kb.isc.org/docs/cve-2024-1975 Note to anyone running 9.18 series (which means at least all Debian 12 installations) that the "fix" for this CVE in that branch is the complete removal of SIG(0) dynamic DNS update support. Not just a disabled-by-default config option, but the actual removal of the relevant code.

The actual mitigation for the issue is only available in the 9.20 series.

IMO this seems like a rather drastic way of doing things for a 0.0.1 patch release to a purportedly stable branch. Anyway reverting https://github.com/isc-projects/bind9/commit/bef3d2cca3552100bbe44790c8c1a4f5bef06798 restores SIG(0) support (along with the vulnerability) for those who prefer to live dangerously.

-Valtteri

On 23 July 2024 we (Internet Systems Consortium) disclosed four vulnerabilities affecting our BIND 9 software:

- CVE-2024-0760: A flood of DNS messages over TCP may make the server unstable https://kb.isc.org/docs/cve-2024-0760 - CVE-2024-1737: BIND's database will be slow if a very large number of RRs exist at the same name https://kb.isc.org/docs/cve-2024-1737 - CVE-2024-1975: SIG(0) can be used to exhaust CPU resources https://kb.isc.org/docs/cve-2024-1975 - CVE-2024-4076: Assertion failure when serving both stale cache data and authoritative zone content https://kb.isc.org/docs/cve-2024-4076

New versions of BIND 9 are available from https://www.isc.org/downloads

Operators and package maintainers who prefer to apply patches selectively can find individual vulnerability-specific patches in the "patches" subdirectory of each published release directory:

- https://downloads.isc.org/isc/bind9/9.18.28/patches/

With the public announcement of these vulnerabilities, the embargo period is ended and any updated software packages that have been prepared may be released.

On 20 September 2023 we (Internet Systems Consortium) disclosed two vulnerabilities affecting our BIND 9 software:

- CVE-2023-3341: A stack exhaustion flaw in control channel code may cause named to terminate unexpectedly https://kb.isc.org/docs/cve-2023-3341 - CVE-2023-4236: named may terminate unexpectedly under high DNS-over-TLS query load https://kb.isc.org/docs/cve-2023-4236

New versions of BIND 9 are available from https://www.isc.org/downloads

Operators and package maintainers who prefer to apply patches selectively can find individual vulnerability-specific patches in the "patches" subdirectory of each published release directory:

- https://downloads.isc.org/isc/bind9/9.16.44/patches/ - https://downloads.isc.org/isc/bind9/9.18.19/patches/ - https://downloads.isc.org/isc/bind9/9.19.17/patches/

With the public announcement of these vulnerabilities, the embargo period is ended and any updated software packages that have been prepared may be released.

-- Best regards, Michał Kępień